Tested on Linux - works fine. Next up is a re-test with PowerShell on Windows 10 Pro / Docker for Windows and a README for the process, since it's not the same as on Linux or a Mac.

After my testing on Windows, which failed, because the volume mounting of "." into the API container /code wasn't working. So I've built a one-step development environment creator that doesn't need to mount host files into a container. See README-onestep.md.

I've tested it on Linux and will test it on Windows tomorrow. There's one piece left to do: design an iteration workflow and supporting scripts. The scheme I'm thinking of is:

1. The developer brings up the environment. Right now there are no command-line conveniences on the images but they're easy to add.
2. The developer works on the code. The databases can be maintained from the host via pgAdmin or psql, and the code can be edited via docker exec.
3. When the developer is satisfied with the code and database, a "dumpall" will snapshot the database and docker cp commands will fetch the code.

Tested and working on Linux host using docker-machine / VirtualBox connection. Everything works.

@znmeb what was jessie used for?

@mxmoss There were some files that images built on Debian "jessie" used - now that both images come from "stretch" they're not needed any more.

Latest test update - works on Windows 10 Pro from WSL Ubuntu using the Disaster Resilience backup file I have salted away. I've added the .env file I used to the repo.

@mxmoss is testing on Windows 10 Home with Docker Toolbox. So far he's just run into line ending problems.

Tested on Windows 10 Pro / Docker for Windows from a git bash window - works.

Question: does staticfiles need to be in version control? It's built in the container and I'm copying it down to the repo, but it's in .gitignore so it doesn't get version-controlled. Should it be?

Status update:
This pull request addresses two issues
- containers crashing on any Windows host because Git checked out files with Windows (CR-LF) line endings and the script interpreters can't deal with them, and
- containers crashing on Windows 10 Home because Docker Toolbox uses a VirtualBox virtual machine and host files aren't getting mounted into the containers.

The only test that hasn't been completed is testing whether the new code works on Windows 10 Home, which uses the Docker Toolbox / VirtualBox method. And I'd like someone to test the new one-step builder on a Mac before we merge this.

this will take a little time to get through. 2 questions from quick glance:

1. this onestep setup process, is this a replacement or an alternative to current startup?
2. the theme related .env files, the idea is to provide these as more ready to go samples within the repo?

1. The one-step is the only one that will work for Windows 10 Home, so I consider it an alternative. There are too many descendants of this repo in the wild for it to be a replacement. And there will probably be a third process for building production API containers, involving Travis CI.
2. The other two .env samples are mostly a convenience for testing - I don't think they need to be in the repo when we merge.

What is the recommended workflow and stack for running the images on Windows 10 Pro?

the theme related .env files, the idea is to provide these as more ready to go samples within the repo?

I've actually been thinking about this subject... Incidentally, I suppose I also came to the same conclusion as Ed independently, because I also just put a disaster.env file into the root of the disaster-resilience-backend repo. It has the postgres values set to the correct values to match my disaster.backup that gets restored. The motivation was that when a user first clones a backend repo, they must cp the sample.env to the correct filename and then set three of the values inside of the file. Otherwise, or if they are unaware or don't know the correct values, they get errors when building the image. So instead of greeting the user with the necessity of getting all that correct and the probability of not doing so, I thought it would be easier if I just provided the file and probable values in an example file (kind of like the sample.env does). The values should match the settings in the postgres DB backup file that the repo is likely to use, in my case the disaster.backup with postgres as DEVELOPMENT_POSTGRES_OWNER/_USER and disasater as DEVELOPMENT_POSTGRES_NAME.

I suggest that we consider some type of mechanism like this that relieves the user of the burden of the necessity of having to set up the database settings, where possible.

cool, we do want to make it easy as possible for folks to get up and running easily, so sounds good. i just wasn't 100% sure why, and there is nothing in readme/docs.

I guess documenting the intention of the onestep, providing link from main readme to that one might be good?

Yeah - more documentation is always good. Has anyone tested this branch on a Mac? I want to make sure forcing the line endings to Linux mode didn't break a Mac.

This line ending stuff is tricky - I probably should re-code it so only files that run in the container are forced to Linux mode. Also, separate the scripts into a folder that runs in the container and a folder that runs in the host.

I feel that by including the default.envs we can remove a significant hurdle to the first time quickstart application generation and build/start process.

No I don't have any access to Mac environments.

@znmeb What example .env files do you currently have? I have one that works for disaster.backup, but not any others. Also related - for the PRODUCTION_POSTGRES_ secret I removed their values, leaving them blank, before I checked mine in.

I have one for each of our two databases ... One is in there now

The project seems to be progressing well without this pull request - @nam20485 @mxmoss @bhgrant8 should I cancel it and close the issues "wontfix?""

I vote for cancelling it. Because it seems like its not necessary, and in looking at the commits, it appears to be a lot of change for something that is not necessary.